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Opportunity for U.S. Developers 

“Next year Atari is going to attack American 
markets,” said Atari’s Sig Haitmann. “Sam TVamiel has 
stated that in 1989 Atari will establish itself as one of 
the major computer companies in the U.S.” 

This yeai; Atai'i has been shipping computere 
primarily to European mai'kets. “The ST is now a stand- 
ard throughout Europe,” said Haitmann. Atari’s big 
push to gain the same presence in the U.S. is already 
undemay. New dealer promotions with excellent retail 
pricing ane being combined with regional advertising. 
And Atai'i’s sales staff is signing up new dealers, much 
to the delight of developers. 

Developers Can Profit in Europe 

Still, it may take some time before Atari’s installed 
base in the U.S. matches that of Europe. Developers can 
maximize returns on their investment in Ataii by 
marketing their products in Europe mai kets. Atari sub- 
sidiaiies in the United Kingdom, Germany, and France 
have set up their own software distribution channels. 
Atari "would like to talk to U.S. developers about 
maiketing US. software thi ough these channels. 

“There is a need for good software in Europe,” said 
Hailmann. Even English-only products from American 
developers can flourish, due to the size of the European 
market and high quality standards. “I would like to talk 
to developers personally about marketing opportunities 
ovei'seas and help them sell their products in Europe.” 
Call Sig Hai'tmann at (408) 746-2906. 

Atari needs the support of its developers, now and 
for future products. By offering opportunities thiough 
European subsidiaries. Atari and its developers can con- 
tinue to forge a strong partnerehip that’s good for 
business on both sides. 

Developer’s Conference 

The long-awaited Atari Developer’s Conference has 
been slated for January 29-30-31. It will be held neai' 
Atain headquarters in San Jose, California. Further 
details will be available soon. 


Atari Begins U.S. Market Push 

Atari’s attack on the U.S. computer market is hap- 
pening! Atai'i launched a fullscale marketing assault on 
America at the Fall 1988 Comdex show, with new pro- 
ducts, sales, and marketing progi'ams. Atari’s Comdex 
exhibit was its lai'gest ever, occupying the 6,000-square 
foot Gold Room at the Las Vegas Convention Center. 

Atai'i is reentering the U.S. marketplace, and the 
Comdex show, held November 14-18, provided the perfect 
opportunity for the company to make a statement to 
its dealere, developere, and the industry. Atari showed 
such exciting new softwaie packages as DeskSet 1 1 and 
UltraScript, and high-tech hardware like the 
MEGAFILE 30 and MEGAFILE 60 high-capacity disk 
drives, the Atai’i MS-DOS pereonal computere, and the 
Atai’i 'IVansputer Workstation. 

At a meeting with developers and dealers, Atai’i 
President Sam Tiamiel stated that in 1989, Atari will 
establish itself as one of the major computer companies 
in the U.S. The DRAM shortage has lessened, allowing 
increased production. The promotional progiam for 
dealers which commenced in September has gained 
momentum, leading the way to increased sales. Atai’i 
is signing up new dealers daily and upgrading existing 
dealers to cai’ry MEGA products in addition to the 520 
and 1040ST. 

For Comdex, Atari amassed a full line-up of soft- 
ware solutions for business, desktop publishing, CAD, 
graphics, MIDI, education, communications, and 
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Atari Announces PostScript 
Compatibility for SLM804 Printer 

Atari announces UltraScript, a new Postscript- 
compatible page description language interpreter and 
software raster image processor for the Atari SLM804 
laser printer and MEGA 2 or MEGA 4 systems. 
SLM804 printere bundled with UltraScript will be 
available tefore the end of the year, for approximately 
$200 more than the current list price. 

UltraScript uses font scaling technology that pro- 
vides a variety of type that dramatically increases the 
versatility of the Atari Desktop Publishing System. Type 
is treated as a vector image and can be manipulated, 
scaled or rotated. 

UltraScript comes with 16 fonts, including Lucida, 
Lucida Sans, Lucida Typewriter (roman, bold, italic, and 
boldface italic versions), Lucida Symbol, Lucida Hebrew, 
and Lucida Hebrew Typewriter. The Lucida family was 
specifically designed to take advantage of the laser 
marking engines. Lucida has recently been licensed by 
Adobe for use with Postscript. 

TWo font packages will be available with UltraScript, 
providing all the Apple LaserWriter II fonts licensed 
by Adobe from ITC and Linotype for Postscript. These 
fonts include Helvetica, Courier, Times Roman, Palatine, 
Avant Garde, Bookman, New Century Schoolbook, 
Souvenir, Garamond, Zapf Chancery, Zapf Dingbats, and 
Symbol. Additional font packages will become available 
in the future. 

A number of software packages for the Atari are 
Postscript-compatible and may be used with the 
SLM804 and UltraScript. Files could also be imported 
from non-Atari computers. UltraScript includes a pro- 
gram interface that dlows developers to provide applica- 
tions with the ability to print Postscript files without 
user intervention. 

Ultrascript was developed for Atari by the Santa 
Clara, CA-based Imagen, a subsidiary of QM& 

New Products 

MEGARLE 30 

Atari’s MEGAFILE 30 offers the convenience of 
high-capacity disk storage for MEGA or ST computer's. 
Designed like Atari’s new MEGAFILE 20 to fit with 
the MEG A’s processing unit, the new drive offers a full 
30 megabytes of memory. MEGAFILE 30s are currently 
being shipped in place of the MEGAFILE 20 in the 
MEGA4 Desktop Publishing package, at no additional 
cost. 


Atari Begins Push at Comdex 

continued from page 1 
entertainment. The Atari computer product line was 
displayed with the work of over 50 developers. Con- 
tinuous product demonstrations took place on a stage 
at the center of the Gold Room. 

Desktop Publisiriit!’. Atari showed DeskSet II, a 
professional-level desktop publishing system that offer's 
flexibility and versatility in working with text and 
gi'aphics. Atari also showed UltraScript, the revolu- 
tionary new Postscript emulator for the MEGA 2 or' 
MEGA 4 and Atari SLM804 laser printer. UltraScript 
enables the Atari to produce high-quality type and pr o- 
cess Postscript files fi'orn other systems. 

Computer Systems. At Comdex, Atari demonstrated the 
Atar'i TY-ansputer Workstation (ATW). This powerful 
computer is based on one of the world’s fastest pro- 
cessors, the Inmos T800 transputer. Atar'i has combined 
processor power with a high-resolution gr'aphics sub- 
system to produce a low cost but high specification 
gener'al purpose workstation. The ATW will exploit the 
potential offered by both par allel processing and the use 
of multiple processors. The sp^ and power of the 
system will make it suitable for applications such as 
desktop publishing, simulation, macro modeling, 
robotics, and speech synthesis. The hi^ specification 
video output makes the ATW good for image process- 
ing, CAD, and TV and film work. Initial shipments of 
the ATW have already been made to developers. The 
price of the ATW is targeted below $10,000. 

Atari also demonstrated its new tine of MS-DOS 
compatible machines. The PC4 is based on the 80286 
microprocessor and is IBM PCAT-compatibla The PCS 
featur'es an 80386 processor and OS/2 compatibility. 
These machines are targeted to begin shipping in the 
U.S. in the first quarter of 1989. 


SFP004 Math Coprocessor Boards 

The SFP004 Math Coprocessor board is now ship- 
ping to developws in limited quantities. Write to Cindy 
Claveran at Atari Corporation to obtain pricing and or- 
der the product 

See the May 1988 issue of The Atari Forum for more 
information on the coprocessor. Address all letter's of 
inquiry to Atari Corporation, 1196 Borregas Avenue, 
Sunnyvale, CA 94086, Attn: Cindy Claveran. 

Developer Kit Upgrade 

'This is your last chance to receive your developer 
kit upgrade for $20! Orders will be filled only through 
January 15, 1989. Refer to the JulyiAugust 1988 issue 
of The Atari Forum for information on the upgrade’s 
contents. 
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Question & Answer 

compiled by John Feugans 
Director of Software Technology 

Here are the latest questions from the Atari developers 
mailbag as answered by John Feagans. Leave questions 
on CompuServe for PIN 70007,1072 or GO ATARIPRO for 
Atari developer SIG information. 

BIOS 

Q: I have a program which works fine on my old 520 
but does not work correctly on my MEGA with the new 
ROMs. Briefly, the problem is this--to save processor 
time I am switching the mouse to absolute mode and 
requesting its position every vblank. The code enclosed 
worked fine but on the new ROMs the mouse does not 
get reset to 0,0 and it moves in an erratic way. 

A: Here is my summary of the code; 

1. Save Al. 

2. Do a bunch of stuff which in the meantime clob- 
bers AO. 

3. Restore Al. 

The old ROMs were saving and restoring register 
needlessly, and so to save the overhead of the additional 
pushes and pops, the new ROMs eliminated these in- 
stnictions. What the above progiam did was to clobber 
a register that previously was restored by the calling 
function. Whenever you write ISRs or mouse handler’s 
be sure to save and restore all the registers that you ate 
using. 

Q: I have to do three assembler routines to get the IKBD 
packet. My routines for the mouse and joystick work 
perfectly, the packet pointed by AO is set like it should 
be when mouse or joystick are moved. But the keyboar d 
routine doesn’t work. Following the Atar’i developer’s 
guide, the IKBD must send a packet each time a key 
is hit. But the packet is never modified. In fact the 
statvec vector routine is never called! (The ikbdsys vec- 
tor routine is called, but the Atari guide gives no infor- 
mation about the way to use it...) Why doesn’t the 
statvec vector work correct!)'? How can I get the statvec 
packet when a key is hit? 

A: The statvec routine is initialized to point to an RTS 
and is never used by the BIOS. That is why your routine 
is never getting called. The IKBD sends two types of 
packets for a key strike. The first is a make c(^e and 
the second is a break code If your program sits there 
monitor-ing packets, not much will appear’ to be happen- 
ing. That is because the data is not sitting in any visi- 
ble register’s- the packets are built fr’om several 
characters and there may be characters unprocessed 
waiting in the ACI A. The ikbdsys vector is called when 
there are characters waiting on the ACIA. The ikbd 
handler has several state variables and pai’ses out the 
ikbd packets and calls the appropriate subsystem vectors. 

AES 

Q: Is there a way to position the text cursor inside an 
editable text field before calling the for ni__do? 


A: There is no way to pie-posilion the cursor in an i 
editable text field. The ob_spec field in the object points 
to a TEDINFO sti’uctui’e which contains a pointer to 
the place wher’e the data gets stored. I generally allocate 
a string and set the pointers to it rather than using 
valuable r esource file space for the data. There ar e several 
example programs in the data libraries and upload ar’eas 
of both GENIE and CompuServe. 

Development Tools 

Q: How do you include inline assembler in a C pr ogr am 
using the Atari Developer's Kit? 

A: This is a perennial question and I am repeating it 
for the benefit of those who nray not have seen the an- 
swer before There are two ways to do this depending 
on the number of lines to enter. If you have just a line 
or two to do then the asmO function is the one to use; 
asm(" trap #1"); 

One assembler statement is included per asrn{). The sec- 
ond way to do it is to create a small file and allow the 
linker to link it to your C ptegr’am. A last word of advice- 
the Alcyon compiler adds an under’scote to the begin- 
ning of your C labels. Alcyon labels are unique to 8 places 
and counting the underscore that means you must have 
uniqueness to 7 character’s. 

VDI 

Q: There are many bindings for the AES which 1 must 
include with my C progi’ams but there does not appear’ 
to be acorresponding binding VDIBIND.H. Am I miss- 
ing it from my developer's kit? 

A: 'VDIBIND.H is not necessai’y because all functions 
return an integer value. There is not a problem with us- 
ing the VDI functions - all are defined in the VDIBIND 
object libr’ary. 


New Online 

The following files for developers are new this month 
in data library 7 (for registered Atari Developers only) 
in the Atari Developers SIG on CompuServe and on 
GENIE in Libraries 3 and 4. 

APPI.DOC The Atar’i Page Printer Interface document, 
containing information for writing to the DMA printer 
controller’, 

SALADARC SALAD is the sequel to the “Long-Awaited 
Line-A Document,’’ and includes mote information, such 
as negative Line-A variables. 

INTERFAC.ARC This is the source code to accompany 
the ai’ticle “Accessories, Pop-Ups, and Main Applica- 
tions," in the JulyAugust 1988 Atar i Forum newsletter. 
IMG.TXT This is the same IMG file format as in the 
currently shipping developer's kit. If Appendix I in your 
kit has four file formats (RLE, extended RLE, raster 
encoding, raster ran encoding), then you need this docu- 
nrent. 

AESBIND.ARC New AES bindings with form button 

and foi’in_keybd; includes documentation. 
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Atari’s Fall Dealer Promotions 

Ataii announced its new Fall promotion last month, 
offering consumer incredible deals on Atari computer 
systems and increasing advertising dollars for dealers. 
Ataii is also signing up new dealem daily and upgi'ading 
existing dealem to cairy MEGA products in addition 
to the ST. 

Ataii Computer's new fall promotions feature a pric- 
ing and legiond advertising campaign for the 520STFM , 
MEGA 2 and Atari Desktop Publishing systems. 
Response to the promotion has been good. "Overall, the 
promotion has been meeting or exceeding our sales ex- 
pectations," said Mike Dendo, vice president of sales. 
"As a result of the M EGA 2 promotion, our dealere have 
been able to upgi'ade many cuirent customers to the 
more powerful machina They also have been selling more 
to the power-oriented home user and the small business 
person." 

520STFM 

Ataii is cunently offering the Home Education 
package, featuring the upgi'aded 520STFM, a color 
monitor, two Bentley Beai‘ educational titles, Ataii's 
Home Planetaiium, and a sophisticated color giaphics 
progi'am for a suggested retail price of $849.95. A 
monochi’ome system, including two games and Microsoft 
Write, is $649.95. 

All 520STFMS cumently shipping have double-sided 
internal floppy disk drives. Now all ST floppy drives can 
read and write 720K disks. 

MEGA 2 

The MEGA 2 promotion offers a monochrome 
system for only $1299 suggested retail, for a limited 
time. '"The MEGA 2 is a veiy strong product and a very 
strong value," said Denda "Atai'i is providing dealere 
with a progi-am that addresses the price'performance 
needs of the customer." 

Desktop Publishing 

In a continuing promotion for Atari Desktop 
Publishing Systems, a bundle including a monochrome 
MEGA 2, SLM 804 laserprinter, Microsoft Write, a VT- 
100 teiTOinal emulation progi’am, and LDW Power, a 
Lotus-like spreadsheet, retails for a suggested $3095. 

A monochrome MEGA 4 Desktop Publishing 
Package includes the MEGAFILE 20 20-megabyte hai’d 
drive, a teminal emulation progi’am, and Timework's 
Desktop Publisher ST, for $4395 suggested retail. 

All promotional pricing continues through 
December 24, 1988, with the exception of the MEGA 
2 system. The $1299.95 price expires November 30, 1988. 


Best of the Boards 

compiled by J. Patton 
Atari Developer Support 

Captui’ed threads this period span CompuServe, 
GEnie, and Usenet (the network accessed through col- 
lege, government, and industry Unix mail and some pub- 
lic BBSs). Messages range from implementing GE.M 
functions to a frank discussion of supervisor mode to 
useful code fragments. Most threads cover a variety of 
topics under a general header and these messages il- 
lustrate their extent. 

GENIE 

From the GEnie programming roundtable is a con- 
ference which begins with a question about redrawing 
after ucc.'s, ends up with an implementation of 
WF_NEWDESK. 

J.IRVINl IJarrelll 

Uh, hmm... 1 seem to be having a problem with some 
desk accessories vs. my progiam. Both the old and new 
controLacc from Ataii, and a few other desk acc's, leave 
behind a giey "shadow" when they ai’e closed. If all desk 
accessories did this it would make more sense to me, 
but most of them do properly close and blit back 
whatever they coveied up. 1 am using Mai’k Williams 
C vereion 3, and using their resource editor. 1 am sim- 
ply drawing a main menu and one other object, not open- 
ing a virtual workstation or creating any windows, i£.: 
appLinitO; 
rsrc_loadrtest.i’sc" ■); 
rscr__gaddr(0,TOPMNU,&nienu_addr); 
giaf_niouse<ARROW,&nowhere); 
giaf_m{Mise(M_OFF,&nowhere); 

rscr_gaddr(0, FORM, &obj adi); 

form_centeriobj_addr,&x,&y,&w,&h); 
objc_draw(obj_addr,0,MAX_DEPTH,xy,w,h): 
menu_bar(menu_addr, 1 ); 
graf_mouse(M_ON,&nowhere); 

evnt keybd(blah,blah,...|; 

appLexitO: 

rscr_free0; 

exit(O); 

As I understand it, my program is not responsible 
for the desk accessories, so what gives? I am assuming 
that each desk accessory may either: 

Use the foms librai’y and therefore use form_dial 
to save and blit back whatever they cover up (nice, polite) 
or— 

Open a window, not saving anything they cover up, 
and expect the Explication to handle all scieen redraws 
(gi’umble). 

SO, am 1 forced to open a window just so that I can 
get the WM_REDRAW message so that I can redraw 
my object when a windowed desk acc exits? (This is kind 

continued on next page 
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continued from previous page 

of a drag only because it takes a noticeable amount of 
time to i«draw my object) OR ... am 1 missing something 
here ? 

Jaj'rell li^vin 

ALANPAGE 

GEM desk accessories ai'e not required to blit back 
what they cover up. All form_dial does is cause a ledraw 
message to be sent. If you ai’e drawing a dialog box or 
other object directly on the desktop, then you will not 
get a ledraw message: Instead, the GEM desktop gets 
the redraw message and then ledraws the grey 
backgi'ound (gieen on a color monitor) right on top of 
your dialog box. 

If you open up a window and draw your box inside 
the window, then you will get a redraw message. It's also 
possible to make an object part of the desktop itself, 
but 1 have not tried this myself and don't know the 
details of how to do it. 

Alan 

The desktop doesn’t really redraw anything while an 
application is running— the AES does. The desktop is 
“swapped out" while applications run. 

—Ken Badertscher 
Atari Corporation 

DOUGH 

If you’ie just displaying a form on the desktop, then 
you will probably be better off redefining the desktop 
backgi'ound to include your form, as Alan suggested. 
It really is quite simple. Just go to the RCS, create a 
lai'ge box with a suitable fill pattern. Then, place your 
form inside of it. You must make the desktop box big 
enough to cover the entire scieen, less the menu bar, 
and I've found it easiest to get the scieen size horn the 
extended inquire function or the XBIOS call getrez, and 
diiectly adjust the sizes within my progi'am. This allows 
for resolution independence with only one resource file. 
Tb infoim the desktop progiam of the change, use a 

wind set call with the WF NEWDESK paiameter 

and supply it with the address of the foim. Now, the 
desktop progiam will handle all lediaw messages! Before 
your program exits, be sure to again call wind_set with 
WF_NEWDESK, this time supplying the value OL for 
the tiee address. This is undocumented but necessary 
to inform desktop to use its original backgi'ound, which 
is important if the user runs the program from a shell 
other than the desktop. Oh, I should say the menu bai' 
itself is two pixels higher than the default character cell 
height for the given resolution. Hope this helps... 

Doug 


A.HAMILTONI [Alan H.] 

An addendum to the above: The wind_set() call does 
not draw the new desktop initially. You have to 
objc_draw() it yourself, or send a redraw message to 
the screen manager via foim_dial(), with the entire 
scieen as the aiea to lefi'esh. 

If you aie using form_doO, you don't need to worry 

about what accessories aie doing, since fomi do() takes 

control of the computer and won't allow the menus to 
drop down. 

Alan 

The one thing missing fro.;: *his discussion is a good 
way to get the screen size for the form that you use to 
replace the default desktop. The methods described by 
Doug H. rely on undocumented features that may not 
be supported in future TOS versions: 
u Using Getrez and adjusting the object size yourself 
makes your program depend on hardware configurations 
that you know about. Future hardware enhancements 
(eg. large screen monitors) will cause problems with this 
scheme. 

m Using the screen values from the extended inquire lor 

from the v opnvwk call) means that you are relying 

on the AES to redraw the menu bar over your 
WF^EWDESK’ed form. 

The recommended solution is to use wind get us- 

ing the desktop window handle to get the correct dimen- 
sions: 

int x,y,w,h; 

OBJECT *new_object^tree; 

/* get correct dimensions for new desktop object */ 
wind_.getiQ, WF_WORKXYWH, cSj, &y, &u\ 
&h ); 

/* set object size and draw it */ 

objc^chungel new_object_tree, 0, 0, x, y, w, 
h, 0, TRUE ); 

1* replace the desktop with your object tree */ 
wind_set( 0, WF_NEWDESK. 
new_object_tree, OL ); 

which will give you the working dimensions (area sans 
menu bar) of the “base” window ■ the desktop.' You can 
then use those dimensions to set the size of the object 
which you are using to replace the desktop, with the 
assurance that your code will work on new hardware 
and new OS software. 

—Ken Badertscher 
Atari Corporation 

COMPUSERVE 

From CIS to Atari the topic is Calling GEM in 
supervisor mode, (k: 543 - 1061 S7/ATAR1 Reg. Devel.j 

Fm: Stefan Daystrom @ Hybrid 76237,562 
Tb: Julius Okiamcak (ATARI) 70007,1070 (X) 

I read or remember somewhere that your applica- 
tion shouldn't be in Supervisor and call GEM... 

continued on next page 
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continued from previous page 
My progiams (in 4xForth) run in super mode from 
beginning to end. That seems to work fine, as long as 
you allocate some user stack (about 256 bytes seems 
way more than enough, I've found 128 even to be quite 
sufficient) sepai'ate fi'om your super stack as some GEM 
calls (such as appLinit and fseLinput) put stuff on 
the user stack regaidless of which mode you're in when 
you call them (don't ask me why!). 

Fm; John Feagans (ATARI) 70007,1072 
Tb: Stefan Daystrom @ Hybrid 76237,562 (X) 

Could you be more specific where you read this info 
about super mode? It is a fact that if you enter the AES 
in super mode you may not still be in super mode upon 
return. 

Fm: Stefan Daystrom @ Hybrid 76237,562 
Tb: John Feagans (ATARI) 70007,1072 (X) 

I didn't read about always being in super mode, 1 
do it! That's the way 4xForth works, and 1 and many 
progiammere I work with have patterned both Forth 
and assembly and C progi’ams after that manner. The 
switch to super mode is done very eai'ly in the progi'am 
(in C, in the init segment) via the GEMDOS call, and 
it simply stays that way forever. FORTH requires this 
as it is not just a language but a development environ- 
ment, and partially substitutes for a SID-style debug- 
ging progi’am. I have never had a problem with finding 
myself not in super mode upon return from an AES call. 
The only problems 1 have had were if I didn't maintain 
a small user stack when calling AES, even if in super 
mode when I made the call, and if I didn't allocate that 
users stack within my progiam (the new TOS's 
fseLinput can clobber the user stack if you simply in- 
herit the one at the top of memory that the system gives 
you). 

Fm: John Feagans (ATARI) 70007,1072 
Tb: Stefan Daystrom @ Hybrid 76237,562 (X) 

I have no idea how making AES calls while in super 
mode could ever work. The AES pays no regal'd to the 
current state of super mode when it restores things. I 
stand coiTected on the documentation-you have to read 
between the lines. On page 39 of the old hitchhiker's 
guide it says “DRI hasn't bothered to document this 
function yet." The function was Tap #1 function 0x20. 
They did not document it in GEMDOS because they 
knew it wouldn't work right with AES calls. 

Fm: Stefan Daystrom @ Hybrid 76237,562 
Tb: John Feagans (ATARI) 70007,1072 (X) 

“I have no idea how making AES calls while in 
super mode could ever work. The AES pays no 
regal’d to the current -state of super mode when 
it restores things. " 


Sure it does! It returns with an RTE, doesn t it? 
A TRAP put the SR on the stack and an RTE pops it 
back off. And the SR contains all the necessaiy infor- 
mation (including whether the user was in super or user 
mode) to get things back to the right place. 

Fm: John Feagans (ATARI) 70007,1072 
Tb: Stefan Daystrom @ Hybrid 76237,562 

The official Ataii position is do not make AES calls 
from super mode. You may do so at your own risk. 

Derek Mui sez: It is not recommended to make any 
AES calls when the program is in supervisor mode 
because u\c:e is the potential danger of corrupting some 
data. 

First, there is a design issue. The AES always 
assumes the caller is in user mode. It never tries to 
distinguish if the AES call is being made from super- 
visor mode or user mode. So, there isn't any function 
to preserve the user sUtck if the call is being made from 
user mode. 

Secondly, the AES trap handler will try to save some 
register values onto the user stack. It could be a prob- 
lem if the program is running in supervisor mode all 
the time and never sets the user stack to the proper urea. 
In this case, the sy.stem could get a bus error or address 
error. Things could get worse if the user stack belongs 
to some other sleeping process and we are writing 
something into its area. By the time that process is wak- 
ing up, it may be getting garbage from its stack. 

USENET 

A contiibution originating from Usenet: How do you 
detect warmboot? (Newsgroups: comp.sys.atari.st) 

From: apratt@atai’i.UUCP (Allan Pratt) 

In ai’ticle [2003@kallioperice£dul bro@titan.ricejedu 
(Douglas Monk) writes: 

How can you tell in a program in the auto folder 
if it is being run after a coldboot or a warmboot? 
And 1 answered: 

The only appropriate way is for the first incaina- 
tion of the progi am (the one which ran after a cold 
boot) to leave its fingeiprint somewhere that the 
second incar nation— after the wai m boot— can find 
it. 

After this sentence, I got lost in something about 
_memtop... I should have said this: 

The progiam looks for its cookie first, to see if it 
has run before. There's code for doing that below. If it 
doesn't find its cookie, it does the “first incai’nation" 
stuff below. If it does find the cookie, it does the “second 
incai’nation" stuff. 

The first incarnation of a progiam does whatever 
it needs to do on coldboot, then leaves a magic cookie 
ai’ound to tell later incarnations that this stuff has been 
done. One suie-fire(*) way to protect memory from 

continued on next page 
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subsequent erasure (until another cold boot) is to move 
_memtop. 

During the first nin, after cold boot, move 
_memtop down by the size of whatever you want to 
be reset-sui-vivable. Include in that space your magic 
cookie The kind of magic cookie 1 suggest has two 
longwoids: one is a pointer which points to itself, and 
the other is a magic number which you should strive 
to make unique for all applications: 

magic equ $38371656 ; random, hopefully 

unique ID. 

; aO contains the address where we will put our 
cookie 

movel aO,(aO) 
movel #magie4(a0) 

After moving memtop, you must cause a reboot. 

The best way to do this is to find the OS HEADER: 
its address can be found at _sysbase In the header, 
you’ll find the address of the reset handler at offset 4. 
Go to supervisor mode and jump there for a reset. 

(*) This is only sure fire assuming other progi-ams don’t 
come along and move _memtop back up. 1 f other pro- 
grams move it DOWN to reserve even more memoiy for 
themselves, that’s okay. 

The next incaimation of your progi'ani will find the 
cookie and do the things it needs to do when it knows 
the RAM is already reserved. 

Finding the cookie consists of looking through RAM 
stai'ting at what it finds at _memtop and going until 
it nms out of RAM (and gets a bus enor). This will take 
a while because you don’t get bus error until you pass 
4MB. Sony. Here’s some code which will do what is 
necessary. 

_memtop equ $436 

_sysbase equ $4f2 

; run this in super mode to find the cookie style 

described above 

find_cookie: 

move.1 8,al ; save old bus err handler 
mov&l #.buserr,8 ; install our new one 
move.1 _memtop,aO 
•loop: cmp.l (aO),aO 
bnes .nomatch 
cmp.l #magic,4(a0) 
beq.s .match 
.nomateh: 

addq.l #2,a0 
bras .loop 

.match: movel al,8 ; restore bus err handler 

movel aO,dO ; return cookie match address 

in do 
rts 

: got a bus error: 

; means we failed to find our cookie before running 

out of RAM 

.buseiT: 


addq.l #1 4,sp ; clean off the exception frame 
move.1 al,8 ; restore old bus err handler 
moveq.l #0,d0 ; return zero for failure 

rts 

; run this in super mode to cause a wai'mboot 

cause wai’mboot: 

movel sysbaseaO 

movel 4(a0),a0 
jmp (aO) 

No warranty is expressed or implied. This techni- 
que might take some tuning. Use at your own risk. Your 
actual mileage may vary. 

Opinions expressed above do not necessardiy reflect 
those of Atari (3orp. or anyone else. 

—Allan Pratt, Atari Corp. 
...ames!atari!apr-att 


Sam Traniiel Online 

Atari President Sam Tramiel conducted a live con- 
ference on CompuServe last month, with online atten- 
dance of about 100 users. Mark Jansen, technical editor, 
typed for Sam Tramiel. The conference was moderated 
by CompuServe SysOp Ron Luks. 

At the conference, Sam said Atari would begin ship- 
ping in earnest to the U.S. market in early 1989, including 
the ST, MEGA, Atari's line of PC-compatibles, and the 
newest products, such as the Atari Transputer Worksta- 
tion (ATW, formerly known as theAbaq). The following 
is a portion of the conference. 

(Richard Mataka) As you know, there are only a few US 
publications supporting the ST. Now Compute ST has 
decided to no longer publish and with the questionable 
support from Atari, Wottl Perfect Corp seems to have 
put their pi’oduct development on hold. Also other soft- 
ware third-party companies are not supporting the ST. 
How will you convince these companies and others who 
may start a company to support the ST? What kind of 
incentives will you be offering or will you just let 
everything conre out of Eurepe which is where the cur- 
rent bulk of ST support is based? 

(Sam T’umiell I am as frustrated as you are and pro- 
bably more so. ...the present problem is that the DRAM 
problenr is causing us great delivery problems and we 
cannot keep up with the demand in Europe and other 
parts of the world. We just signed a major deal with 
a big DRAM supplier and the situation will get better 
1 hope in eariy 1989. 

We will and do support developers all over the world 
and suggest that US developer's lear-n how to export 
which would help themselves and the economy. I am 
sorr-y to see Compu ‘e drop the ST mag but I hope that 
they will revisit the issue when they see tens of 
thousands of STb sold monthly in the US... 

continued on next page 
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Last month 1 was in Gemiany for the Annual Atar i 
Fair in Dusseldorf. It was incredible, over 30,000 over 
the weekend. 

(Richard Matakaj Sam, 1 think that that may be where 
your main problem is user suppor t is excellent, however 
development support is ver y ver}’ strained...and it is the 
development people that you have to win over if you 
are going to be a serious computer competitor in the US. 
(Sam Tramiel) We are not strain^H, and are happy to help 
anyone... I am sui'e once we are selling large quantities 
in the US any strains that exist will disappear'. In the 
meanwhile, export to Europe We do, and we like it! 
(Charles Medley) What is the news on the 68030 TT? 
(Sam TYamiel) We are working on the TT, and hope to 
show it in ear ly '89. Until then, no further cornnrents 
on the TT... but it will knock your socks off! 

(Steve Mortimer/NNQ) M any developers and dealers are 
not going to support the ST anymore or ar e on the brink 
of that decision. It is essential to retain what support 
we have left. Will you consider advertising to incr'ease 
awareness till the "big push ' or sign up a national com- 
puter chain stocked with a few S1^ diverted from 
Europe? 

(Sam TYamiel) We feel that advertising without product 
availability is helpful in selling our competitor's' 
machines, and therefore, will just waste money. 


As far' as a national computer chain is concer ned, 
we are ali'eady diver ting machines to the US and ship- 
ping them to our few but loyal ST dealers... 
(Shawn Smiley) Ar'e you planning to make any additions 
to the ST like stereo sound and speech synthesis? 
(Sam Tramiel) No comment. Sor ry, but we do not want 
to promise new things until they are ready. 

(tc) What about the portable ST? Fact or fiction? 
(Sam Tiamiell Fact. We are working on it, and will ship 
it as soon as it is ready. 

(Steve Mortimer) Do you forsee any major changes at 
Atar'i or the ST mar'ket in the near' futur'e.. This includes 
the possibility of a revamped ST based on new 
technology like the 68020/30 while remaining ST com- 
patible? 

(Sam Tramiel) 1 hope so...we plan for Atai'i to be number- 
two or nutrrber' three in the world per-sonal corrrputer 
mar ket and we hope to make the ST one of the stand- 
ar'd machines in the US during 1989. 1 would prefer not 
to comment on details of future ST or TT machines at 
present. 

At the conclusion, Sam indicated another online con- 
ference would be scheduled in the near future. In his 
closing remarks he said, ”I appreciate the support of 
all of you, and I really hope that in 1989, you will not 
be such a minority in the US personal computer world. 
It is a pleasure to see Atari so successful in Europe and 
I'm sure that with more DRAM as we expect in '89, 
we will be able to be successful in the U.S. as well." 


Developers! Improve Distribution 

Atari is compiling a pr'oduct directory for- dealer's. Tbll us how to contact your distr ibutorfs) and we'll 
pass the information to Atari's authorized dealers. Make sure the r'ight people know about your product! 

Send the coupon below to Atar'i Computer, Sales Support, 1 196 Bortegas Avenue, Sunnyvale, CA 94086, 


Company Name 

Product 

Distributor(s) 

Address 

Phone Contact 







